[memory/cryptolib] Launder status output#28810
Conversation
Since the hardened memory operations just return OTCRYPTO_OK the compiler optimizes the status output which circumvents the control flow integrity. An example is 20011276: | | 9e2080e7 jalr -1566(ra) # 2002bc54 <hardened_memcpy> 2001127a: | | 73900513 li a0,1849 Launder the status output to circumvent this. Once there is another call in place which makes the possibility to return a different status, this launder is no longer needed. The assembly files were checked for similar patterns, only a single call in RSA had a similar result. Signed-off-by: Siemen Dhooghe <[email protected]>
siemen11
requested review from
alees24,
johannheyszl and
nasahlpa
and removed request for
a team and
alees24
siemen11
added
the
CherryPick:earlgrey_1.0.0
nasahlpa
left a comment
nasahlpa
left a comment
There was a problem hiding this comment.
Thanks Siemen!
A question - would it make sense to have this as a macro and replace OTCRYPTO_OK with this macro? Or is this a too heavy overhead and we only should use (status_t){.value = (int32_t)launder32((uint32_t)OTCRYPTO_OK.value)} where needed?
Looks a lot of overhead to be honest. This should only be needed for "leafs" so functions that do not call other functions |
nasahlpa
left a comment
nasahlpa
left a comment
There was a problem hiding this comment.
Thanks Siemen, I agree - we only should use that pattern where needed.
|
Successfully created backport PR for |
3 participants
Since the hardened memory operations just return OTCRYPTO_OK the compiler optimizes the status output which circumvents the control flow integrity. An example is
20011276: | | 9e2080e7 jalr
-1566(ra) # 2002bc54 <hardened_memcpy>
2001127a: | | 73900513 li
a0,1849
Launder the status output to circumvent this. Once there is another call in place which makes the possibility to return a different status, this launder is no longer needed.
The assembly files were checked for similar patterns, only a single call in RSA had a similar result.